Enabling API-based Tool Integration through Aspect-Orientation*

The Goal: Realising model-based tool integration. With the rise of model-driven software development, more and more development tasks are being performed on models. Seamless exchange of models among different modeling tools increasingly becomes a crucial prerequisite for effective software development processes. Due to lack of interoperability, however, it is often difficult to use tools in combination, and thus, the potential of model-driven software development cannot be fully utilized. To tackle this problem, we are currently realizing a system called ModelCVS [4] which is based on semantic technologies and a set of model integration patterns for metamodel integration. Problem: Often no tool metamodels available. Ideally, model transformations are specified between the metamodels representing a tool’s modeling language and are executed with a dedicated QVT model transformation language (e.g., ATL [3]), which, for instance, transforms a model of a UML Activity Diagram into a model of a BPEL process specification. In many cases, however, tools do not offer an explicit metamodel ready for model transformation in the sense of QVT. For practical applicability, it is of crucial importance that a tool integration system also offers the ability of integrating tools through a programming interface (API). An ad hoc approach would be to implement an Observer which listens to events issued from the source tool’s API and delegates the semantically equivalent method calls towards the target tool’s API. Thereby, the events will be propagated in a way as that modifications in the source tool are reflected in the target tool appropriately. Although this approach does not require an explicit metamodel representation, manually incorporating the notification code into the tool’s source code is problematic. On one hand, this can prove to be cumbersome or even impossible, and on the other hand, with respect to separation of concerns, this glue code should not be mixed with the tool’s native code. Solution: Aspect-orientation to the rescue. Aspect-orientation can provide a clean solution in terms of encapsulating the notification mechanism within an aspect, thus avoiding the need to interfere with the tool’s source code. The aspect code as well as the observer code that actually performs the transformation can be derived from a set of semantic correspondences established in an API weaver, which in turn could be built on a tool like AMW [1]. In our case, weaving would be an activity of establishing semantic correspondences between API method calls, for instance. The left-hand side of Figure 1 shows how these correspondences can be used to weave two tool APIs. Problem: ‘Mysterious’ APIs. Even though tools may provide a public API, especially proprietary or open source tools often lack documentation and may not be well understood, which makes an immediate weaving merely impossible. As an example, instead of providing a set of distinct factory methods for object creation (e.g., createClass(), createAttribute(), ...), generic-sounding and parameterized methods (e.g., create(String[] params)) may be used for object creation. Furthermore, the problem of not knowing which sequence of method calls constitutes a valid model manipulation arises. Solution: Event Recording. Hence, a systematic method, which allows to reveal the inner works of a tool’s API is proposed. The right-hand side of Figure 1 depicts a user-guided process which records (2) API events (e.g., method calls) occurring after certain tool interactions (1), like a GUI command or a model import. After a certain interaction is completed, a user’s commit (3) assembles the recorded events as a valid transaction constituting a consistent model manipulation. Instead of the previously mentioned weaving of APIs, the elicited transactions (e.g. sequences of method calls) can now be subject to a weaving step.